home *** CD-ROM | disk | FTP | other *** search
/ Magnum One / Magnum One (Mid-American Digital) (Disc Manufacturing).iso / d16 / netwin3.arc / NETWORK < prev   
Encoding:
Text File  |  1990-09-04  |  10.9 KB  |  277 lines
  1. **********************************************************************
  2. *          Developing Network Applications for Windows 3.00          *
  3. **********************************************************************
  4.  
  5.  
  6. As local area networks (LANs) become increasingly common, application
  7. developers should ensure that their applications run properly in a
  8. network environment.
  9.  
  10. There are two areas that developers should keep in mind:
  11.  
  12. - Applications should be well behaved when shared by multiple users.
  13.  
  14. - Applications that access network software directly might require
  15.   special measures to be compatible with protected (standard or 386
  16.   enhanced) mode.
  17.  
  18. This document discusses each of these areas.
  19.  
  20.  
  21. =======================================================================
  22.                    BEING SHARED BY MULTIPLE USERS
  23. =======================================================================
  24.  
  25. Many corporations are choosing to have their computer users share a
  26. single copy of an application that resides on a network server.
  27. Microsoft(R) Windows(TM) version 3.0 can be run this way. The Windows
  28. Setup /n (network) option configures the user's system so that most
  29. Windows files are used directly off the network, while the user's
  30. personal files and configuration information are stored in a private
  31. Windows directory. (See the "Microsoft Windows User's Guide" for more
  32. information on using a shared copy of Windows.)
  33.  
  34. If you intend to allow shared copies of your application, you must
  35. make sure that two users running the same application will not
  36. interfere with each other. The following sections present rules that
  37. should help you plan your application for network support.
  38.  
  39.  
  40. CREATING PERMANENT FILES
  41. ========================
  42.  
  43. Many applications store configuration files in the same directory as
  44. the application's own executable file. This method will not work for
  45. multiple users, because the application will store each user's
  46. information in the same directory, overwriting other users'
  47. information.
  48.  
  49. Instead, the application should use the GetWindowsDirectory function
  50. to find the user's private Windows directory. This location is
  51. guaranteed to be unique for each user.
  52.  
  53. Refer to the "Microsoft Windows Software Development Kit Reference"
  54. for more information on the GetWindowsDirectory function.
  55.  
  56.  
  57. CREATING TEMPORARY FILES
  58. ========================
  59.  
  60. When creating temporary files, use the GetTempFilename function to
  61. determine the name and location of the file. This function will ensure
  62. that temporary filenames will not conflict, even if multiple users are
  63. sharing the same temporary storage directory.
  64.  
  65.  
  66. USING PROFILE STRINGS
  67. =====================
  68.  
  69. Profile and configuration information is usually stored in
  70. initialization (.INI) files using Windows functions such as
  71. WriteProfileString. These functions fall into two categories: those
  72. that access WIN.INI, and those that access another .INI file specified
  73. by the program.
  74.  
  75. The following functions access WIN.INI:
  76.  
  77. - GetProfileString
  78. - GetProfileInt
  79. - WriteProfileString
  80.  
  81. Since each user has a unique copy of WIN.INI, these functions can be
  82. safely used even when the application is being shared by more than one
  83. user.
  84.  
  85. The following functions access other initialization files:
  86.  
  87. - GetPrivateProfileString
  88. - GetPrivateProfileInt
  89. - WritePrivateProfileString
  90.  
  91. These functions behave similarly to the WIN.INI functions, except that
  92. the application specifies the name of the private initialization file.
  93. When using these functions, you should specify the name of the file,
  94. but not a complete pathname. (For example, MYAPP.INI instead of
  95. C:\MYAPP\MYAPP.INI.) By default, the file will be located in the
  96. user's private Windows directory; specifying a full pathname could
  97. give multiple users access to the same file.
  98.  
  99. The exception to this rule would be initialization files that need to
  100. be shared between all users. Make sure that such files cannot be left
  101. in an inconsistent state if multiple users update them simultaneously.
  102.  
  103. See the Windows SDK Reference for a full description of the
  104. initialization file functions.
  105.  
  106.  
  107. =======================================================================
  108.              CALLING NETWORK SOFTWARE IN PROTECTED MODE
  109. =======================================================================
  110.  
  111. Windows applications running in protected mode require special support
  112. whenever they make a function call to real-mode software. This
  113. includes calls to DOS, the BIOS, or a network. Non-Windows
  114. applications running with Windows do not require this special support,
  115. however, since non-Windows applications running with Windows always
  116. run in real or virtual 8086 mode.
  117.  
  118. The main support required is called "API mapping." If the arguments to
  119. the call include pointers to data, that data should be copied down
  120. into the first 1 MB of address space so that the real-mode software can
  121. access it. The processor is then switched into real or virtual-8086
  122. mode so that the real-mode software can process the call. Finally,
  123. when that call returns, any data it modified is copied back up to the
  124. caller's protected-mode address.
  125.  
  126. Fortunately, most applications interact with the network only
  127. indirectly, by using DOS functions to manipulate files on redirected
  128. drive letters, or by using DOS or BIOS calls to print to a remote
  129. printer using redirected printer ports. Windows applications can
  130. continue to perform these functions normally, because Windows
  131. automatically maps standard DOS and BIOS calls.
  132.  
  133. However, some applications need to use functions that are specific to
  134. a particular network or networking protocol. Some part of software
  135. must map these API, and in some cases this may require special
  136. procedures on the part of the programmer.
  137.  
  138. The remainder of this document describes programming considerations
  139. for designing Windows applications that use the following networking
  140. protocols and networks:
  141.  
  142. - Microsoft Networks and DOS network functions
  143. - NetBIOS functions
  144. - Microsoft LAN Manager-based networks
  145. - Novell NetWare
  146. - Ungermann-Bass Net/One
  147. - Banyan VINES
  148.  
  149.  
  150. MICROSOFT NETWORKS AND DOS NETWORK FUNCTIONS
  151. ============================================
  152.  
  153. Many networks on the market today are based upon the Microsoft Network
  154. standard, also known as MS-NET. These networks support a set of
  155. standard DOS functions that perform network activities, such as
  156. redirecting drive letters.
  157.  
  158. Windows automatically handles these DOS functions. However, in order
  159. to maintain compatibility with future Windows products, your
  160. application should not make DOS calls by executing an INT 21H
  161. instruction. Instead, it should set up all the registers for executing
  162. the INT 21H and then make a far call to the Windows DOS3Call function.
  163.  
  164. See the Windows SDK Reference for a full description of the DOS3Call
  165. function. See the "MS-DOS Encyclopedia," available from Microsoft
  166. Press, for more information on Microsoft Network functions.
  167.  
  168.  
  169. NETBIOS FUNCTIONS
  170. =================
  171.  
  172. NetBIOS is the most widely used networking API. These functions are
  173. normally called using INT 5CH. Windows handles most NetBIOS functions.
  174. However, in order to maintain compatibility with future Windows
  175. products, the application should not make the NetBIOS call by
  176. executing an INT 5CH instruction. Instead, it should set up all the
  177. registers for executing the INT 5CH, and then make a far call to the
  178. Windows NetBIOSCall function.
  179.  
  180. The following rarely-used NetBIOS functions are not supported:
  181.  
  182.   71H       Send.No.Ack
  183.   72H       Chain.Send.No.Ack
  184.   73H       Lan.Status.Alert
  185.   78H       Find.Name
  186.   79H       Trace
  187.  
  188. See the Windows SDK Reference for a full description of the
  189. NetBIOSCall function. See the "IBM Local Area Network Technical
  190. Reference" for more information on NetBIOS.
  191.  
  192.  
  193. LAN MANAGER-BASED NETWORKS
  194. ==========================
  195.  
  196. Networks based on Microsoft LAN Manager can be installed in either
  197. Basic or Enhanced versions.
  198.  
  199. All versions of LAN Manager support MS-NET and NetBIOS functions.
  200. However, if you are running LAN Manager Enhanced with the API option,
  201. applications can also use a powerful set of networking functions.
  202.  
  203. Non-Windows applications can call these functions by linking with
  204. DOSNET.LIB, a static library provided with their network software.
  205. Windows applications, however, must use dynamic-link libraries called
  206. NETAPI.DLL and PMSPL.DLL. They are distributed on every LAN Manager
  207. version 2.0 Enhanced workstation. However, these DLLs will not run on
  208. LAN Manager 1.x or 2.0 Basic, so these functions may only be used on
  209. LAN Manager 2.0 Enhanced.
  210.  
  211. See the "Microsoft LAN Manager Programmer's Reference" for more details
  212. on writing Windows applications for LAN Manager.
  213.  
  214.  
  215. NOVELL NETWARE
  216. ==============
  217.  
  218. Novell NetWare supports MS-NET and, optionally, NETBIOS functions,
  219. which are described earlier in this document.
  220.  
  221. In addition, Novell NetWare also supports the NetWare and IPX/SPX API
  222. sets, all based on INT 21H.
  223.  
  224. Windows applications can make NetWare calls, but not by executing the
  225. INT 21H directly because this method is not supported in all Windows
  226. operating modes. Instead, you should replace the INT 21H instruction
  227. with a far call to the NetWareRequest function. This function is
  228. exported by name from the NetWare DLL, and should be imported to your
  229. module-definition (.DEF) file as NetWare.NetWareRequest.
  230.  
  231. Windows applications cannot make IPX/SPX calls at this time, although
  232. Novell plans to make this support available in a future release. If
  233. you need more information, contact your usual Novell support channel.
  234.  
  235.  
  236. UNGERMANN-BASS NET/ONE
  237. ======================
  238.  
  239. Ungermann-Bass Net/One is based upon the Microsoft Network standard.
  240. It supports standard MS-NET and most NetBIOS functions, which are
  241. described earlier in this document.
  242.  
  243. Net/One also supports private extensions to the NetBIOS function set
  244. (functions 72H-7DH). These functions are supported by the standard
  245. Windows product. You can call these functions as you would standard
  246. NetBIOS functions, by making a far call to the NetBIOSCall function.
  247.  
  248.  
  249. BANYAN VINES
  250. ============
  251.  
  252. Banyan VINES supports the standard MS-NET and, optionally, NetBIOS
  253. functions. There is also a toolkit for applications that write
  254. directly to the VINES API.
  255.  
  256. Windows applications can call the MS-NET and NETBIOS functions as
  257. previously described.
  258.  
  259. VINES version 4.0 does not support Windows applications calling the
  260. VINES API directly, but Banyan does intend to make this support
  261. available in VINES 4.1. For more information, contact your Banyan
  262. support channel.
  263.  
  264.  
  265. Microsoft and MS-DOS are registered trademarks and Windows is a
  266. trademark of Microsoft Corporation.
  267.  
  268. Banyan and VINES are registered trademarks of Banyan Systems, Inc.
  269.  
  270. Novell and NetWare are registered trademarks of Novell, Inc.
  271.  
  272. Ungermann-Bass and Net/One are registered trademarks of Ungermann-
  273. Bass, Inc.
  274.  
  275. IBM is a registered trademark of International Business Machines
  276. Corporation.
  277.